1. Field of the Invention
The present invention relates, in general, to financial transaction software, and, more particularly, to software, systems and methods for processing transactions in a regulated exchange in a distributed fashion.
2. Relevant Background
The present invention relates to systems, methods and a computer software architecture for trading in a futures trading marketplace. Futures and options trading are important techniques for coping with the price uncertainty of a free market. Price uncertainty creates risks and opportunities. Futures and options markets provide a forum for commercial interests in a commodity to hedge against price risk by transferring that risk to those more willing and able to bear it, or to those commercial interests with inverse risk profiles. An active futures market provides a readily available, widely accepted reference price for the underlying commodity, thereby improving the efficiency of the overall market. Futures can also be used for investment purposes to mitigate pure financial risks and/or pursue purely financial goals.
A futures contract is a contract between a buyer and seller, whereby the buyer is obligated to take future delivery and the seller is obligated to provide future delivery of a fixed amount of a commodity at a predetermined price at a specified location. The contracts are standardized so that the price of the contract has strong relationship to the value, and the expected fluctuations in value, of the underlying commodity. Futures contracts are traded until a set point in time before the contract-specified delivery date and in many, if not most, cases the positions are closed before physical delivery takes place. Futures contracts are traded exclusively on regulated exchanges. These auction markets include, in many cases, “open outcry” markets as well as electronic trading. A futures market or exchange provides a mechanism where the futures contracts themselves can be bought and sold, much like a stock exchange provides a mechanism in which ownership in business entities can be bought and sold.
These exchanges implement systems that create and manage accounts for buyers and sellers, enable market participants to communicate transaction information, and execute transactions in a reliable fashion. It is desirable to provide these systems in a manner that minimizes transaction overhead. Like any market, a regulated exchange strives to bring many buyers and sellers together. Generally speaking, active markets are considered more efficient. In other words, the larger the number of participants and the larger the transaction volumes, the more likelihood exists that the market will result in fair prices for the products being exchanged. In turn, confidence that prices are fair leads to greater participation. Hence, an exchange's systems and software must support large transaction volumes and scale over time to handle variable transaction volume and numbers of participants.
Another attribute of a strong exchange is the ability to provide buyers and sellers with sufficient information about completed transactions so that they can better value their own transactions. Capturing, processing, and delivering transaction information in real time increases confidence of buyers and sellers. Accordingly, the exchanges strive to provide systems and methods that reliably capture and record transactions, and execute those transactions efficiently and precisely.
An exchange also attempts to control transaction risks. While market participants accept risks associated with the underlying products they are purchasing (e.g., commodities futures and options), they desire to lessen risks associated with the marketplace itself. For example, in any transaction a potential exists that a buyer will not have sufficient funds to complete a purchase. To protect against this “counterparty credit risk”, exchanges require that market participants maintain a certain level of liquid assets on deposit called margin. As soon as anyone buys or sells a futures contract, they must deposit with their clearing member an amount of money that the exchange determines is sufficient to cover any one-day price move. As long as that person or firm holds on to the contract, the exchange must maintain minimum margin funds on deposit for that position, with the contract holder depositing additional funds whenever the market moves against him.
Contract values change continuously, however, and so exchanges implement processes to periodically assess the current value of customers' holdings and adjust margin requirements accordingly. “Clearing” refers to the processes of registration and settlement of a trade that includes provisions for margin requirement and performance guarantee. The “settlement price” is the price established by the exchange settlement committee at the close of each trading session and is the official price to be used by the clearinghouse in determining net gains or losses as well as margin requirements. In an active exchange the process of daily clearing involves millions of computations and account postings that must be performed in a very few minutes. Accordingly, the software and systems required to support this exchange activity are very complex.
Open outcry trading takes place on a physical trading floor where brokers exchange bids and offers for futures contracts. Executed trades are then recorded by hand or entered into an electronic recording system. The completed trades are later sent to an external or internal clearinghouse to process the trades and issue appropriate reports to the futures exchange and its members. Futures markets are also maintained on electronic trading systems. These electronic trading systems allow entry of a bid or offer for a particular futures contract. One can also enter orders for combinations of futures orders, e.g., spread or strip orders. A spread order buys one or more futures contracts and sells one or more futures contracts simultaneously at a single “differential” price. A strip order buys (or sells) two or more futures contracts simultaneously at a stated differential price from the previous settlement prices for each contract in the strip or at an average, i.e., “flat,” price. The orders are time stamped by the trading system as they are entered. The system then matches a bid with an appropriate offer. Bids and offers are matched in the sequence in which they are received, hence, a buyer does not select a particular seller. The trading system then generates appropriate information for the clearinghouse.
Automated trading systems are complex software systems that assist exchanges in their efforts to implement the various process required by the exchange. These systems implement a variety of functions such as order entry, order validation, buy-sell order matching and publishing information in a form that is useful to transaction clearing entities. All of these functions are performed in a reliable, auditable fashion so that customers of the exchange can be assured of consistency. Automated futures trading systems were initially developed to support conventional trading by capturing data from trades executed by floor brokers. Such systems include processes for recording executed trades, rejecting unacceptable trades, and clearing acceptable trades. However, these systems are working with executed trades and so did not include processes for automating many of the tasks that were handled by the floor brokers.
Electronic trading systems that receive orders over a network, on the other hand, desirably include processes for executing trades. Early systems included processes for receiving orders over a network, but then handled those orders through a floor broker in a traditional manner. Another requirement for electronic trading systems is that they interface with the existing trading systems that support floor-brokered trades. Because of this need some systems have simply tacked on an electronic transaction interface to an existing centralized trading application. However, such approaches impose the deficiencies and limitations of the centralized trading application onto the electronic trading application.
Transactions must either be completed in a manner that satisfies both the buyer and seller, or must be discarded. A partially completed transaction is not allowed. A partially completed transaction is one that satisfies the buyer, but not the seller, or a transaction that satisfies both the buyer and seller partially, but not fully (e.g., when only a portion of both of these orders is filled). This factor, in combination with the highly specialized nature of trading systems, has led to centralized software implementation. These prior systems comprise complex, tightly coupled components that would execute on one or more mainframe computers.
However, complex, centralized software systems tend to be expensive to obtain, inflexible, and difficult to maintain. The tight coupling and interdependence between functional components leads to unexpected results when components are upgraded or added. When the systems are based on mainframe computer environments, the hardware acquisition and maintenance is also expensive. As a result, these systems are slow to adapt to newer technologies and to support new business initiatives.
Often times centralized trading systems do not scale well. In the field of trading system software, it is not acceptable to have a system that fails when faced with large transaction volume. Accordingly, centralized systems are built from the beginning to support the largest expected transaction volume, even though this level of activity may be rarely if ever used. When the trading activity approaches the designed limit, the system must be replaced or extensively reworked in order to support the larger transaction volumes. It would be desirable to implement trading system software and systems that scale gracefully to avoid the expense and disruption associated with system replacement.
Centralized trading systems, also called trading platforms, tend to offer limited and proprietary interfaces to external systems. Because a centralized system implements all or nearly all of the trading functions internally, there is little need for communication with external systems. Operators can be specially trained to handle various activities such as order entry and report generation, and so the systems tend to have limited, difficult to use interfaces to both humans and other machines. However, there is an increasing desire to allow trading firms to use front-end applications that best fit their trading requirements. It is therefore desirable to be able to implement trading systems with improved ability to communicate with a wide variety of software and third party systems.
In many fields of software development, complex software is now being implemented in the form of distributed systems. These systems include functional components with a high degree of logical separation so that each component is largely insulated from the actions of other components. Distributed systems leverage the improved abilities to communicate between system components so that complex functions can be implemented as many small components. These smaller components are easier to design and maintain, and provide much greater flexibility in adapting to a variety of computer hardware/operating system environments. Until now, however, distributed system architectures have not been applied to trading system software.